The use of constituent vectors when creating a complex system model today meets a burgeoning need since more and more systems are being constructed by assembling a number of exemplars (or instances) of constituents (also known as components). The problem then arises as to how to describe such architecture models and convert them in order to study their properties.
To illustrate the problem, let us consider products of the communications network type. To be more precise, by way of example FIGS. 1 and 2 illustrate the case of an Ethernet switch.
FIG. 1 shows the functionality required 10. The frames received at each of the input ports must be retransmitted as quickly as possible to one of the destination ports or to the other three ports (“broadcast”) as a function of the destination address found in the incoming frame. Clearly, the desired performance levels require the maximum number of simultaneous transmissions and with no loss of frames.
The top part of FIG. 2 shows a possible functional architecture solution 21 representing the necessary internal functions and couplings between these functions. It is clear that the architecture has to be based on receiver (“Receiver[1:N]”) 23 and transmitter (“Transmitter[1:N]”) 24 vectors in line with the number of switch ports and that frame routing requires a set of relations by message queues of the FIFO (“First-In First-Out”) type.
The bottom part of FIG. 2 is a possible proposal for representing the internal hardware architecture 22. A vector of p processors (“Proc[1:p]”) 25 is used and the processors communicate via a common memory 26. Each processor has two parts (ProcRx 27 and ProcTx 28) and which are also coupled via a bus 210 and a local memory 29.
FIG. 2 shows the advantage of the component and relationship vector concept in describing complex new architectures.
But the use of this vector concept, which simplifies representation, compounds the difficulty of two aspects:                verifying the detailed behaviour of the functional model because each element of each vector is not identified separately; and        constructing the architectural model resulting from mapping (denoted 211 in FIG. 2) the functional architecture on the hardware architecture. Indeed, it becomes almost impossible to be able to map each function or functional relationship vector element (constituent vectors of the functional architecture) on a processor, bus or memory vector element (constituent vectors of the hardware architecture).        
A new degree of complexity also arises with configurable products of the FPGA type and which justifies the use of the instance vector concept. Indeed, the very architecture of these components enables the instantiation of any number of processors, memories, FIFOs and buses, and does so according to very different topologies.
Two techniques are known, in the prior art, for describing the functional or physical models (also known as platforms) of complex systems.
In the first known technique, almost exclusively used today, describing complex system models involves individually designing each modelled constituent, and all interconnections between the modelled constituents. The model of each constituent may come from a model held in a phase library so as to facilitate duplication.
The major drawback of the first known description technique is the significant time needed for keyboarding and the non-generic character (in other words the non adaptation to a modifiable number of constituents).
In the second known technique, used today only in a few special circumstances, the description of complex system models is based on a mechanism that allows the multiplicity of the constituents to be indicated (instance vector notion in the aforementioned sense). The interconnections then comply with rather regular patterns.
This technique for the representation of a model (application model or platform model) by using multiple instances of constituents (functions and relations, or processors, memories and communication nodes) has been used in the aforementioned CoFluent Studio (registered trademark) tools since June 2005.
It is set out in detail in the following work published by the inventor of the present application: “A System-Level Performance Model and Method. Jean-Paul Calvez, Chapter 2 in Meta-Modeling: Performance and Information Modeling. pp 57-102-1996 CIEM Vol 6 (Current Issues in Electronic Modeling). Edited by Jean-Michel Bergé, Oz Levia, Jacques Rouillard. Kluwer Academic Publishers ISBN 0-7923-9687-1”.
It will be noted that a function, a relation, a processor, a memory or a communication node, is represented for example in the graphical form of a rectangle or a circle with its shadow in order to indicate multiplicity. However this form of representation is not restrictive. Any form can be used to represent said concept (text for example in the form of a vector [1:N]).
The second known technique considerably simplifies the work of keyboarding the models and gives a better structure to their regularity and their genericity. Multiplicity (instance vector notion) may be described for any level in the hierarchical model representation. The instance vectors (also known as multiple instances) may be nested.
However the second known technique has the drawback of much restricting the architecture possibilities. Indeed, each instance vector is considered as a non-decomposable constituent and can therefore only allot itself overall to a single processor type resource. A processor instance vector cannot be used directly since it is not a simple matter to define function mapping on each vector processor. Moreover, all the elements of a vector have the same properties.
Another drawback of the second known technique is that it does not facilitate verification of the model obtained either. Indeed, simulating this model provides a time flow which is quite complex to understand and subject to wrong interpretation given the stacking of instance vector states (multiple constituents) (see the example in FIG. 6).
The above drawbacks lead to the situation in which the designers do not create or create only a few models of such architectures. Such architectures are therefore not studied and potential solutions not explored or only with great difficulty, which leads to difficulties in taking decisions in respect of such products.
The present disclosure provides a technique for simulating a complex system with construction of at least one model of said system, said technique enabling the instance vector concept (in the aforementioned sense) to be used without however restricting the architecture possibilities (better exploration of solution architectures) and facilitating verification of the model or models constructed (in other words detailed analysis of model behaviour).
The disclosure provides a technique of this kind which is straightforward to implement and inexpensive.